This program is SHAREWARE. I don't care if you just have it hanging around, but if you find it useful, be considerate and send $35.00 to make me feel good. You will note that I have not disabled any features or added an expiration date.
I can be contacted at:
Stephen Knight
c/o JSR Synergetics
1115 East Main St.
Rochester, NY 14609
or CompuServe: 76377, 52
----------
Online HELP: Look under the 'About SignalEditor' for more of an explanation as to what the program is capable of doing. Also, the 'Settings' item under the 'Spectrum' menu has a help function that can give specific information as to what you would be setting.
----------
Known Bug:
After doing a waterfall, the program seems to get into a window-update cycle. This is shown by an occasionally flickering watch cursor. If you click
on the waveform displayed in the window, the cycle is then broken. If you choose to ignore the problem (the cursor will stay as a watch), the program will still function correctly.
Suggestions as to the cause/cure will be most welcome.
----------
Some answers to the inevitable questions:
"The version I have complained about being a Mac II or later version"
Ñ I have two versions (SignalEditor and SignalEditor II) that should be traveling together. One is for the Mac II series or later, and uses code for
the 68020/68881 (or later) processors. If you have the wrong one, check with your source. If you don't have any luck, check macserve@pucc or CompuServe.
----------
"It seems to spend a lot of time accessing the disk when opening and closing the file and cut/paste/copy seems to do alot too."
The problem with editing signals comes from a choice between speed and
the number of samples that fit into memory. I could have made the program try to load in ALL the samples when editing a signal, this would have made the program extremely fast. Unfortunately, there is always going to be the case of too many samples, so you would only be able to work with signals that had fewer samples than you had memory.
I decided to compromise. The program only keeps the samples in memory that it needs at one time (currently 50K samples). The rest are kept in a temporary file until needed. When asked to display more samples (like a signal 60K samples long), it cheats and only shows the first 50K samples of the area selected. Since the samples are primarily on disk, cut/paste/copy do a very brute force shifting of the necessary samples to/from their appropriate spot. It may be crude, but it seems to work. When I figure out a better way, I'll be sure to put it in, but so far everything I've thought of has had some nasty drawbacks.
----------
"Ok, so it only displays a certain amount. How do I get at the rest of it?"
To get around the problem, I implemented two keystrokes that let you
scroll through the signal (albeit slowly). They are, the LEFT ARROW and RIGHT ARROW keys. Each time you hit one, the current signal area in use will scroll the signal, either left or right, by approximately 10%. The larger the amount of time displayed, the greater the scrolling effect.
----------
"When I do the waterfall spectrogram or spectral slices on my SE/Mac+, it goes very slowly."
While my FFT routine is not the fastest, none are very quick. When it comes to signal processing, horsepower is a vital neccessity.
----------
"There's a bug here, now what?"
Although there are bound to be some 'features' that people don't like, I will try to compromise if enough registered users complain. If it is a bug, please send me a description, with as much technical detail as possible. I can be reached through the information on the 'About...' dialogs. If I can eliminate it, I promise to send you a new version, hopefully without the bug.
----------
"How about..."
If it doesn't look too bad to implement, sure. Warning: I might not have any idea how to implement it, so you might have to explain how (slowly). An ongoing dialog with registered users will insure improvement and expanded utility in future releases.
